package enums

/**
 * 项目生命周期对应的代码运行环境
 *
 * https://shawn-nie.github.io/2021/10/11/%E9%A1%B9%E7%9B%AE%E7%94%9F%E5%91%BD%E5%91%A8%E6%9C%9F%E7%9A%84%E7%8E%AF%E5%A2%83%E7%B1%BB%E5%9E%8B(Environment_Types)/
 *
 */

/*
 * 使用 iota 和 consts 可以方便地定义整数值的枚举。
 * 通过实现 String() 方法，可以为枚举值提供描述。
 */
//type EnvType int

/*
 * 定义一个枚举值包含编码和描述的结构体
 * 通过结构体封装编码和描述，能够提供更多的灵活性和可扩展性，适用于更复杂的需求。
 */
type EnvType struct {
	Code int
	Name string
	Desc string
}

var (
	/*
	 * COB环境也通常被称为”COB测试环境”; 可以被理解为”PROD环境的备用环境”。当PROD服务器发生了故障或出现一些自然灾害而无法正常工作时,COB环境将迅速接替PROD进行响应与服务， 保持服务的正常运转。
	 * COB环境所部属的应用及数据版本、用户权限、访问权限通常也与PROD(生产)环境保持同步。
	 */

	COB = EnvType{Code: 10, Name: "cob", Desc: "生产备用/COB测试环境"}

	/*
	 * 面向外部用户的环境，连接上互联网即可访问的正式环境。
	 * PROD环境是应用程序正式对外的服务环境; 即程序或一次update的Release版本。
	 * PROD环境通常在收到UAT认证(UAT Sign-Off)并通过适当的变更管理流程之后，由专门的实施者在这里部署相关的版本；
	 * 并由官方渠道(如项目官网, AppStore等)公开提供给真实的使用者。
	 * 在这个环境，真实的用户将会使用最新Release的功能， 并将他们的问题/使用环境通过反馈渠道反馈给产品运维团队。
	 * PROD环境一般会关掉错误报告，打开错误日志 (日志级别: ERROR)；在这个环境，相关的权限仅被分配给真实的产品使用人员，
	 * 开发/测试工作人员将不再有权访问PROD环境的应用。
	 */
	PROD = EnvType{Code: 9, Name: "prod", Desc: "生产环境"}

	/*
	 * 性能评估测试（压测） 外部用户可以访问，但是服务器配置相对低，其它和生产一样。
	 * 类似于“彩排”； 是产品进入生产环境(PROD)前的最后一步。
	 * 预发布环境所有的环境配置参数、架构和代码版本完全相同, 在这里，开发团队进行冒烟测试。
	 * 当所有的团队成员， 包括UI/ 后端开发人员、Devops、DBA等对产品进行检查，且确认产品功能/内容无误， 产品将会被推向生产环境(PROD)。
	 */
	PRE = EnvType{Code: 8, Name: "pre", Desc: "灰度/性能评估/预生产/预发布环境"}

	STAGING = EnvType{Code: 7, Name: "staging", Desc: "临时环境"}

	/*
	 * 负载测试是一种非功能性软件测试过程, 它反映了被测试的软件在同时被大量并发虚拟用户在特定时段内访问/执行事务时的性能。
	 * 简单来说，即”衡量系统处理大量负载时的性能”。
	 * 负载测试的目标是改善软件的性能瓶颈，提供消除这些性能瓶颈所需的诊断信息。 能够让软件在部署到PROD环境前，
	 * 确保各个组件自身的稳定性和流畅性，符合指定的性能标准。 (因此，与UAT 环境相似， LT环境所在的服务器配置/依赖和性能也与PROD环境基本相同。)
	 * 测试人员在负载测试环境中配置测试来模拟各种用户场景，这些场景可以专注于系统的不同模块(如: 订单结算, 历史记录查询等)。
	 * 在负载测试环境，测试人员可以确定负载在来自不同的地理位置时的行为方式，或负载如何累积随后保持稳定。
	 * 负载测试通常被建议集成到持续集成(CI)周期中，以确保软件能够始终处于正确的状态。这就是我们为什么需要设置负载测试环境。
	 *
	 * 负载测试是性能测试(Performance Testing)的一种。 而性能测试是负载测试和压力测试(Stress Testing)的总称。
	 * 相应的， 大型的项目也会根据实际需求，设置压力测试环境或性能测试环境，用以支持相应类别的性能测试。
	 */
	LT = EnvType{Code: 6, Name: "lt", Desc: "负载测试环境"}

	SIM = EnvType{Code: 5, Name: "sim", Desc: "系统集成与运维环境"}

	/*
	 * 可以被理解为功能测试，主要被用作产品的真实用户的体验环境。
	 * 当程序通过内部测试阶段并准备好接受审批时，团队将会把程序部署到UAT环境。
	 * UAT测试由专门的UAT团队或真实产品用户完成；侧重于业务，所以UAT测试人员通常对业务更精通而不需要关注程序的底层逻辑。 用户根据用例描述测试每一个场景，反馈系统issue。开发人员基于issue对系统影响和对业务impact判断，适当的修正系统或记录业务需求，根据业务优先等级，集成进下一个演进阶段。
	 * UAT环境所在的服务器配置/依赖和性能应该与PROD环境(生产版本)基本相同， 但可以暂不考虑缓存/高负载等复杂性能问题。
	 * 此时开发人员或其他技术人员在UAT环境将不再有权限，只有功能测试人员才被授权访问。
	 * 程序到了UAT环境， 通常日志级别会调整至WARN或ERROR。 同时，环境的配置及测试的标准也将兼顾程序的性能(如压力测试)。
	 *
	 * UAT测试通常又包含Alpha测试和Beta测试两种类型：
	 *
	 * Alpha测试通常在系统测试(System Testing)完成后执行。这种测试通常是在开发人员的控制执行的 客户在开发人员的站点进行测试。
	 * Beta测试仅在Alpha测试完成后执行， 不再受开发人员控制， 由软件的最终用户在一个或多个客户站点进行。 Beta测试权限将会提受信任的用户。
	 */
	UAT = EnvType{Code: 4, Name: "uat", Desc: "用户验收测试环境"}

	/*
	 * 和UAT有点相似，但两者不一样。QA测试更加专注于产品自身的质量。
	 * QA测试用于确保产品在交付到UAT环境/流程之前避免错误和缺陷。
	 * 而QAT与UAT的取舍、选择或组合也因团队实际需求而异，也取决于项目管理的方法:
	 * 在瀑布模型中， QAT通常在UAT之前；而在敏捷开发模型中，QAT和UAT则是相互依赖，不一定要按照先后顺序来完成。
	 */
	QAT = EnvType{Code: 3, Name: "qat", Desc: "质量保证环境"}

	/*
	 * SIT环境用于开发周期结束后，验证开发周期内各个开发模块的交付成品集成效果的测试（非功能测试）。在这个阶段，集成测试的主要目的是校验功能、性能和可靠性要求。
	 * 负责SIT测试执行的群体通常是技术项目测试人员 (QA)；少数情况下也可有开发者的介入。
	 * 测试人员根据用例描述测试/模拟每一个功能使用场景； 如在测试过程中发现错误或其他问题，QA测试团队将会为开发团队创建任务或defect进行修复。
	 * 在DEV和SIT环境，应用的日志级别通常会设置较低(ALL/DEBUG/INFO或WARN)， 便于调试和验了解状态。
	 * 软件在SIT环境的配置通常与DEV环境基本相同，也没有研发团队外部的人员进入。
	 * SIT的主要功能是测试系统各个部件之间的依赖关系，因此回归测试 (Regression Testing)是SIT的重要组成部分。 在一个Sprint中的最小可行产品(MVP: Minimum Viable Product) 也只有在SIT测试通过后才会发布。
	 *
	 * SIT可交付的成果则传递给UAT(用户验收测试)。
	 */
	SIT = EnvType{Code: 2, Name: "sit", Desc: "系统整合测试（内测）"}

	/*
	 * 外部用户无法访问，专门给测试人员使用的，版本相对稳定。
	 *
	 */
	TEST = EnvType{Code: 1, Name: "test", Desc: "测试环境"}

	/*
	 * 用于开发与编码阶段 外部用户无法访问，开发人员使用，版本变动很大。
	 * 用于开发周期内，开发人员对自己(团队)实现的代码进行访问/联调与基本功能验证。
	 * DEV环境服务器的配置相对较低，不会考虑太多负载/压力/缓存等性能因素。
	 */
	DEV = EnvType{Code: 0, Name: "dev", Desc: "开发环境"}
)
